home *** CD-ROM | disk | FTP | other *** search
/ Hackers Handbook - Millenium Edition / Hackers Handbook.iso / library / hack99 / insmod.linux.txt < prev    next >
Encoding:
Internet Message Format  |  1999-04-11  |  4.3 KB
  1. Date: Tue, 30 Mar 1999 22:08:13 -0500
  2. From: Brian Szymanski <bks10@CORNELL.EDU>
  3. To: BUGTRAQ@netspace.org
  4. Subject: linux insmod bug/security vulnerability
  5.  
  6. Howdy all,
  7.  
  8. Recently I discovered a bug in insmod that would require a lot of time
  9. and luck to exploit, but is nonetheless important for systems wanting
  10. rock-solid security (security shouldn't be a matter of luck). In short,
  11. when insmod is called without a full path to the module to load, it
  12. checks a small path to find the module in question. By default, this
  13. path is the current directory followed by the /lib/modules/ heirarchy.
  14. In the widely distributed versions of the software, the module is not
  15. checked for root ownership, and there is no way to tell which file has
  16. been loaded after insmod is called. Needless to say, putting a malicious
  17. user's code in to the kernel and then running it in kernel mode is a
  18. very Bad Thing.
  19.  
  20. LINUX DEVELOPERS, HOWTO-WRITERS, ETC... TAKE HEED!!!
  21. The listed maintainer of the program, Jacques Gelinas
  22. (jack@solucorp.qc.ca), informs me that modprobe (not insmod) should be
  23. used to load pathless modules from the /lib/modules heirarchy, but in
  24. practice most people (and precanned scripts) use insmod, compounding the
  25. problem. It appears that the well distributed versions of modprobe are
  26. NOT vulnerable to these bugs (tested on debian 2.1). ***Please change
  27. any documentation you write or scripts you distribute to use modprobe
  28. instead of insmod ASAP*** This should probably be forwarded to some sort
  29. of linux development list, but I know of none at the moment.
  30.  
  31. VERSIONS AFFECTED, IMPROVED (if not fixed) VERSION:
  32. The versions included in debian, redhat, and most if not all other
  33. distributions are vulnerable as well. Any version previous to 2.2.2-pre6
  34. (available from
  35. http://www.pi.se/blox/modutils/modutils-2.2.2-pre6.tar.gz). Please
  36. upgrade to this version, which one of the package maintainers, Bjorn
  37. Ekwall (bj0rn@blox.se), informs me fixes the following issues:
  38.  
  39. o A module has to be owned by root.
  40.  
  41. o All "path-less" modules are resolved according to the list of
  42.   paths in conf.modules (explicitly or via the built-in defaults).
  43.   Note that all module utilities use the same configuration
  44.   and thus the same paths in the new release.
  45.  
  46. o If insmod is called without a path to the module, insmod will
  47.   print the full path of the module it actually selects to install.
  48.  
  49. PROBLEMS IN THE NEW VERSION:
  50. The new version is a big improvement, but not perfect (after all, it's a
  51. pre-stable version...) The last 2 points appear to be implemented fine,
  52. but the first is imperfect. The root ownership checks only appear to
  53. happen when the path to the module is not specified. I don't see any
  54. reason why you would ever need to load a module owned by a user, when
  55. you can just su and copy /chown it. Also, there is some oddness when a
  56. module in /lib/modules isn't owned by root. insmod spits out 24(!) lines
  57. like this:
  58.     insmod: /lib/modules/2.2.4/misc/vmmon is not owned by root
  59. That's better, but I still don't like the idea of bugs in this area of
  60. the code...
  61.  
  62. Another thing to be wary of: There may be some unresolved issues with
  63. groups and permissions, but it'd probably just be bloat for this package
  64. to worry about warning of those issues (IE, mode  a+w modules or g+w
  65. with group != root). Then again, linux's swapon checks for the proper
  66. permissions on a swapfile/device, so perhaps it wouldn't be unreasonable
  67. to warn about permissions.
  68.  
  69. I don't see what's so hard about just checking for ownership and
  70. permissions issues *after* resolving the full path of the module, but
  71. then again, I've been too lazy to RTFS so far, so sue me if it isn't
  72. that trivial.
  73.  
  74. EXPLOIT:
  75. As previously mentioned, an exploit would require a lot of luck and
  76. time, but would basically consist of regularly throwing a lot of
  77. trojan'd .o files in /tmp, and waiting until root decides to clean out
  78. tmp right before loading some module... Far-fetched but too possible for
  79. comfort. Other scenarios along these lines could be imagined. Equally
  80. far fetched, but the point is the currently distributed versions don't
  81. do it the Right Way... It's a lot more likely that you would make your
  82. system crash and burn due to this bug (although files do seem to be
  83. checked to be in elf format before being loaded).
  84.  
  85. Thanks for reading. Comments and constructive criticisms more than
  86. welcome:
  87.  
  88. Brian Szymanski
  89. bks10@cornell.edu
  90.  
  91.  
  92.